Devices that generate, store, use, process or communication sensitive or private data require particular security measures. For example, communication with the device may need to be encrypted and/or authenticated both at the device and at a remote server or station interacting with the device. This can be particularly important for unattended devices or those that do not typically have interaction with users. Such devices may include Customer Premises Equipment (CPE) and machine to machine (M2M) devices, for example.
Data handled by such devices may include passwords, user IDs, security keys and private or sensitive data such as location, medical data, vehicle driver data (for automotive cases, insurance usages etc.) Furthermore, parts of a code base running on the device may also be considered very sensitive and require protection. This code may include industrial secrets (such as details about what the device is doing and how it works) and also personal sensitive information (a device may have different installed libraries covering different sorts of medical conditions, driver characteristics for vehicles, age, gender, learner driver status and other information).
Any or all parts of these sensitive data may need to be used locally within the device and/or communicated securely with external parties (such as a management server). In particular, sensitive code needs to be protected when being executed locally and also communicated over the air during code or firmware updates. In other words, sensitive data needs to be protected both in transit and at rest.
Sensitivity (for both data and code) may encompass both confidentiality of information but also (and sometimes more importantly) the integrity of the information. It is important that devices run the right code or libraries and that there is confidence that these have not been tampered with. Tampering may lead to security vulnerabilities and hijacking of the device for unintended or malicious purposes.
Protecting data at rest (i.e. when it is not being used by the device or while the device is not in operation) by encrypting it on the device is a known technique. However, this comes with key management problems. Furthermore, it can be difficult to use a single key to protect data or code both at rest and in transit (e.g. in use or with the device operational), which can in turn require encryption of the same data several times. This has significant processing, power and energy overheads. Integrity of code on devices is often managed by secure boot processes. However, this can also have its own limitations.
Encryption of data and/or code may be carried out on a device. This may be to frustrate local tampering or to protect the privacy of a legitimate user in the event that the device is stolen, for example.
A difficulty with this is that the key to decrypt the data (and/or code) may also need to be stored on the device. Alternatively, a human user may enter the key, or some information from which the key is derived (PIN, password or fingerprint for example). The key may also be stored within the device but in an “obfuscated” way (e.g. split into several of portions or held in unexpected locations). The key may be stored within the device in secure hardware (e.g. a Trusted Execution Environment, a Secure Element, Smart Card, a UICC with SIM/USIM/ISIM, etc.)
Similarly, these techniques may be used to store a secret key used to verify the integrity of data or code on the device.
Integrity of code may alternatively be achieved by asymmetric methods. The legitimate code image may be signed with a private key (either a root private key, or an end entity private key, which has a certificate signed under a root private key) and verified on the device using a public key (root public key or end entity public key). This has restricted usage on low end devices (it requires support of public key operations), performance problems (boot may be slow), and a number of significant limitations on the achievable security.
Existing solutions for secure key storage are particularly inadequate for M2M use. Many M2M devices have no user interface and no ability to enter PINs or passwords. Even if this was possible then the security that can be obtained from a human-memorable PIN or password is limited and vulnerable to brute-forcing and resetting of any retry counters. Obfuscation techniques are not adequate for determined hackers who may deobfuscate the keys.
Secure hardware is applicable in some cases especially where the device has a SIM card/UICC, but to use it effectively requires putting specific logic and applications in the SIM card/UICC (such as a Javacard keystore and other key handling logic). Such logic is not typically deployed on mass-produced SIM cards. Hence such a solution adds a lot to the cost and complexity to devices that are made with limited functionality and performance. Secure hardware may also be vulnerable to theft and any wipe instruction (for example) may never reach the device or may be blocked from having its intended effect on the device.
The situation for code and data integrity is even more difficult. Public key operations may not be available or may not be fast enough on limited hardware. The root public key may be vulnerable to tampering. If the root public key is stored in memory then the memory may be re-programmed. If it is stored in fuses then these fuses may be reconnected. If ROM storage is used then the ROM chip may be desoldered and replaced with an alternative. If the key is stored in a Smart Card then the Smart Card may be removed and replaced, for example. Public key methods are also unsuited to protecting device-specific boot images, device specific libraries, or device-specific data as they allow data to be moved around between different devices with the same root public key.
There may also be risks related to version rollback (where an old signed code image, with vulnerabilities, is installed instead of the latest code image). Protecting against this vulnerability may require additional (and partially reprogrammable) secure storage to record the latest version (such as additional fuses). The secure boot may not help if the device is powered up for a long time after boot as this can provide plenty of opportunity for tampering during that time.
Furthermore, these solutions may have difficulty when using the same key (or keyset) to protect data and code in transit (for delivery to the device) as used for data at rest. This may require complex decryption and re-encryption. A further problem is that it can be difficult to make the key stored locally on the device (for data at rest purposes) available to authorised parties outside the device.
Therefore, there is required a system and method that overcomes these problems.